Joint  Space  Operations  Center  (JSpOC)  Mission  System  (JMS)  Common  Data  Model: 
Foundation  for  Interoperable  Data  Sharing  for  Space  Situational  Awareness 

Maryann  Hutchison 
Kristen  M.  Kolarik 

The  Aerospace  Corporation 

Jeffry  Waters 

SPAWAR  Systems  Center  Pacific 


Abstract 

The  space  situational  awareness  (SSA)  data  we  access  and  use  through  existing  SSA  systems  is  largely  provided  in 
formats  which  cannot  be  readily  understood  by  other  systems  (SSA  or  otherwise)  without  translation.  As  a  result, 
while  the  data  is  useful  for  some  known  set  of  users,  for  other  users  it  is  not  discoverable  (no  way  to  know  it  is 
there),  accessible  (if  you  did  know,  there  is  no  way  to  electronically  obtain  the  data)  or  machine-understandable 
(even  if  you  did  have  access,  the  data  exists  in  a  format  which  cannot  be  readily  ingested  by  your  existing  systems). 
Much  of  this  existing  data  is  unstructured,  stored  in  nonstandard  formats  which  feed  legacy  systems.  Data  terms  are 
not  always  unique,  and  calculations  performed  using  legacy  functions  plugged  into  a  service-oriented  backbone  can 
produce  inconsistent  results. 

The  promise  of  data  which  is  interoperable  across  systems  and  applications  depends  on  a  common  data  model  as  an 
underlying  foundation  for  sharing  information  on  a  machine-to-machine  basis.  Machine-to-Machine  (M2M) 
interoperability  is  fundamental  to  performance,  reducing  or  eliminating  time-consuming  translation  and  accelerating 
delivery  to  end  users  for  final  expert  human  analysis  in  support  of  mission  fulfillment.  A  data  model  is  common 
when  it  can  be  used  by  multiple  programs  and  projects  within  a  domain  (e.g.,  Command  and  Control  [C2]  Space 
Situational  Awareness  [SSA]). 

AF  Space  Command/A5  (AFSPC/A5)  directed  the  creation  of  the  JMS  Requirements  Model  starting  with  an 
evaluation  of  known  requirements  captured  in  the  National  Mission  Threads  as  they  applied  to  SSA.  Over  six  years 
a  conceptual  model  of  data  terms,  definitions  and  relationships  was  created.  The  conceptual  model  was  used  to 
derive  a  logical  model  of  data  elements  and  attributes  represented  in  Universal  Markup  Language  (UML).  The 
logical  model  was  then  used  to  generate  an  implementable  physical  representation  (e.g.,  extensible  Markup 
Language  [XML]  schema)  which  can  be  used  by  developers  to  build  working  software  components  and  systems. 

The  JMS  Requirements  Model  has  been  mapped  to  the  JMS  Concept  Description  Document  (CDD)  and  has  been 
approved  by  AFSPC/A5CN.  The  JMS  Data  Model  logical  and  physical  components  (also  known  as  the  JMS 
Enterprise  Model  vl.O)  have  been  registered  in  the  DoD  Metadata  Registry  under  the  C2  SSA  Namespace  and  will 
be  made  available  through  bidders'  libraries  to  contractors  for  both  JMS  and  Space  Fence.  Harmonizing  legacy  JMS 
data  interfaces  is  expected  to  take  place  incrementally  during  the  next  two  years.  As  we  add  capabilities  and 
services  to  JMS,  the  JMS  Common  Data  Model  will  continue  to  be  extended  as  needed  to  support  new  development. 


Joint  Space  Operations  Center  (JSpOC)  Mission  System  (JMS) 

JMS  is  an  Integrated,  net-centric  Space  Situational  Awareness  (SSA)  and  Command  &  Control  (C2)  capability 
which  will  rapidly  detect,  track,  &  characterize  objects  of  interest,  using  a  near  real-time  high  accuracy  catalog. 
JMS  provides  timely  space  effects  in  support  of  joint  tactical  operations,  identifying  and  exploiting  traditional  and 
non-traditional  sources.  The  system  performs  space  threat  analysis,  displays  results  via  a  user-defined  operational 
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picture  (UDOP),  develops  a  space  order  of  battle  and  conducts  command  and  control  (C2)  of  space  forces  in  a 
dynamic  environment. 

C2  SSA  Community  of  Interest  (COI) 

The  goal  of  the  Command  &  Control  Space  Situational  Awareness  (C2  SSA)  Community  of  Interest  (COI)  is  to 
ensure  effective  and  efficient  net-centric  interoperability  and  sharing  of  all  significant  SSA  data  and  services  to 
authorized  users.  The  C2  SSA  COI  provides  a  forum  for  organizations  and  entities  to  come  together,  develop 
interoperability  solutions,  including  common  standards,  and  address  issues  of  community  interest  to  support  net- 
centric  implementation  of  space  C2  and  SSA  warfighting  capabilities.  The  focus  of  the  COI  is  on  net-centric 
exposure  and  sharing  of  SSA  and  space  C2  data  required  to  monitor,  assess,  plan,  and  execute  the  intent  of  strategic, 
operational,  and  tactical  commanders.  Programs  rely  on  the  COI  to  help  them  identify,  understand  and  resolve  net- 
centric  and  data  modeling  issues.  COI  members  understand  these  community  needs,  and  are  committed  to  ensuring 
community  products  and  deliverables  are  achieved  in  a  timely  manner  to  meet  program  schedules. 

Participation  in  the  C2  SSA  COI  is  designed  to  include  all  government  or  government-sponsored  organizations  or 
entities  holding  a  significant  stake  in  space  satellite  activities,  including  launch,  maintenance,  control,  monitoring, 
tracking,  conjunction,  service  providing,  service  using,  decay,  and  response.  Consequently,  C2  SSA  COI 
membership  may  include  among  others,  representatives  from  the  Department  of  Defense,  civilian  agencies  including 
intelligence  and  homeland  security,  regional  and  local  government  agencies,  coalition  partners,  commercial 
contractors,  academic  and  private  organizations.  Although  the  membership  is  broad,  the  community  is  focused,  with 
structures,  deliverables,  and  processes  all  designed  to  ensure  an  agile,  efficient  accomplishment  of  community  goals. 

C2  SSA  COI  Structure 
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The  C2  SSA  COI  mission  includes  the  following  tasks: 


•  Develop  a  common  data  model  and  vocabulary  based  on  required  C2  SSA  capabilities  and  associated 
functions  to  share  among  Joint,  Inter-governmental,  Inter-agency  and  Multinational  (JIIM)  partners  in 
planning  and  executing  SSA  and  space  C2  missions 

•  Provide  oversight  for  the  C2  SSA  namespace  on  the  DoD  Metadata  Registry  to  facilitate  C2  SSA  goals, 
ensuring  community  submissions  and  products  are  as  visible,  accessible,  understandable,  and  interoperable 
as  possible. 

•  Provide  a  forum  for  considering,  exploring  and  developing  C2  SSA  net-centric  initiatives  and  products 
within  SSA  and  C2  communities  to  support  on-going  and  future  capabilities. 

•  Provide  outreach  to  community  members  and  facilitate  adoption  of  COI  standards  and  net-centric  products. 

•  Coordinate  as  needed  with  all  appropriate  DoD  and  government  agencies,  civil  and  commercial 
organizations  and  international  partners  in  carrying  out  the  C2  SSA  mission. 

•  Ensure  that  community  products  and  deliverables  are  achieved  in  a  timely  manner  to  meet  program 
schedules. 


The  COI  has  established  a  number  of  Working  Groups  to  carry  out  its  goals.  These  include  the  User  Requirements 
WG  which  supports  the  definition  of  stakeholder  requirements  across  the  community;  the  Data  Model  WG  which 
works  with  the  User  Requirements  WG  to  define  and  maintain  the  COI  Common  Data  Model;  the  Reference 
Implementation  WG  which  builds  working  implementations  of  Common  Data  Model  components  for  use  by  the 
community;  and  the  Adoption  and  Best  Practices  WG  which  provides  guidelines  and  best  practice  information  to 
members,  holds  development  workshops  and  ensures  sharing  of  artifacts  produced  under  the  Reference 
Implementation  WG. 


DoD  Metadata  Registry  (MDR)  C2  SSA  COI  Namespace  Structure 

The  Metadata  Registry  (MDR)  is  established  as  the  official  DoD  repository  for  data  models,  elements  and  XML 
schema  which  may  be  shared  with  authorized  users.  The  MDR  organizes  its  contents  via  Namespaces  based  on 
communities  which  have  a  need  to  share  common  information  and  artifacts.  There  are  currently  hundreds  of 
communities  represented  in  the  MDR. 

As  noted  in  the  DoD  MDR  Namespace  Structure  diagram  below,  the  C2  SSA  COI  portfolio  currently  comprises 
JMS,  Net-Centric  Sensors  and  Data  Sources  (N-CSDS)  and  Space  Fence  programs.  These  programs  require 
interoperable  data  exchanges  to  achieve  success  in  related  mission  areas.  The  data  products  (data  elements, 
attributes,  data  types,  messages  and  XML  schema)  are  produced  by  individual  programs  and/or  created  through 
negotiation  across  collaborating  programs.  Other  related  programs  (shown  grayed  out)  may  eventually  stand  up  a 
presence  within  the  C2  SSA  COI  Namespace  as  they  acquire  a  requirement  to  be  net-centric. 

The  JMS  cloud  will  provide  access  to  a  number  of  projects,  applications  and  web  services  to  accomplish  mission 
responsibilities.  These  SSA  capabilities  (Nyx,  Karnac,  IBEX,  BFS,  ALPS,  CS,  legacy  ESS  A  and  various 
commercial  capabilities)  have  all  created  data  structures  to  support  achievement  of  mission  goals.  These  data 
structures  are  specific  to  the  applications  and  services,  and  commonality  of  these  structures  is  coincidental.  Even 
where  the  data  element  is  one  common  to  multiple  applications,  attribute  structure  is  not  common  so  in  sharing 
information,  mediation  or  translation  must  be  implemented.  This  approach  works,  however,  the  impact  on  system 
performance  will  grow  over  time  as  a  factor  of  number  of  capabilities  which  must  share  information.  In  addition, 
there  is  no  service  orchestration  across  services  and  applications  and  duplication  of  subfunctions  and  procedures 
leads  to  system  footprint  growth  and  the  very  real  possibility  of  inconsistent  results  from  calculations. 
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The  C2  SSA  Namespace  on  the  DoD  Metadata  Registry  (MDR)  is  managed  by  the  C2  SSA  COI  Secretariat.  To 
more  efficiently  manage  data  model  configuration  control  across  the  community,  Space  and  Missile  Center  (SMC) 
has  stood  up  a  C2  SSA  Configuration  Control  Board  (CCB). 


DoD  MDR  Namespace  Structure 
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DoD  Metadata  Registry  (MDR)  C2  SSA  COI  Data  Products 

Programs  within  the  C2  SSA  COI  have  created  and  registered  data  products  on  the  DoD  MDR  to  share  across  the 
C2  SSA  Community.  Some  of  these  projects  have  developed  more  formal  data  structures  with  more  rigorous 
definitions  and  formally  declared  attributes,  UML  models  and  XML  schema. 

Net-Centric  Sensors  and  Data  Sources  (N-CSDS)  taps  into  legacy  sensors  and  has  implemented  a  net-centric 
“sidecar”  or  edge  processor  for  making  this  information  available  to  authorized  users  via  publication  /  subscription 
(pub/sub).  The  N-CSDS  program  has  defined  structures  used  specifically  for  this  information  sharing.  In  the  N- 
CSDS  sub-namespace,  the  program  has  registered  a  number  of  basic  data  types  as  well  as  types  and  messages  for 
sharing  of  optical  information.  In  addition,  N-CSDS  proposed  to  the  larger  COI  a  set  of  types  and  standards 
deemed  sufficiently  common  to  the  C2  SSA  Community  to  be  recommended  for  use  by  all  COI  members.  The  full 
COI  adopted  these  types  and  standards  as  C2  SSA  COI  Common  Types. 
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In  addition  to  the  N-CSDS  data  products,  the  JMS  program  has  defined  an  Enterprise  Data  Model.  The  figure 
below,  DoD  MDR  C2  SSA  COI  Namespace  Data  Products,  illustrates  those  data  products  and  the  sub-namespaces 
under  which  they  are  registered.  These  products  are  made  broadly  available  to  members  of  the  C2  SSA  Community 
to  foster  interoperability. 


DoD  MDR  C2  SSA  COI  Namespace  Data  Products 
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JMS  Enterprise  Data  Model  vl.O 

The  JMS  Enterprise  Data  Model  vl.O  originated  in  a  five-year  effort  under  AFSPC/A5  to  identify  and  capture  all 
requirements  for  the  JMS  system.  This  work  began  with  an  analysis  of  the  SSA  portion  of  the  National  mission 
threads,  and  resulted  in  the  development  of  a  conceptual  model  of  recognized  terms,  their  definitions  and 
relationships.  All  capabilities  enumerated  in  the  JMS  Requirements  Model  were  mapped  to  JMS  CDD  program 
requirements. 

The  JMS  Requirements  Model  served  as  the  conceptual  data  model  for  JMS.  This  conceptual  data  model  was  the 
foundation  for  the  JMS  Logical  Data  Model,  a  UML  model  which  captures  all  required  data  elements  and  attributes 
and  their  relationships.  Finally,  the  logical  UML  model  is  used  to  generate  the  JMS  Physical  Data  Model,  a  set  of 
XML  schema  which  form  the  foundation  for  system  implementation.  The  resulting  model  is  now  referred  to  as  the 
JMS  Enterprise  Data  Model  vl.O  and  provides  a  relational  data  framework  for  data  consistency  across  the  JMS 
enterprise.  The  JMS  program  has  registered  the  JMS  Enterprise  Date  Model,  vl.O  in  the  JMS  sub-namespace. 
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The  JMS  and  N-CSDS  data  modeling  teams  are  currently  working  with  the  Space  Fence  program  to  identify  critical 
data  exchanges  and  to  modify  existing  UML  and  XML  schema  to  facilitate  the  creation  of  new  service  and 
messaging  interfaces  which  meet  Space  Fence  program  requirements. 


JMS  Common  Data  Model 

The  JMS  Common  Data  Model  is  composed  of  the  data  structures,  definitions,  attributes,  XML  schema,  message 
types,  WSDLs  which  are  common  across  JMS  and  one  or  more  of  its  components.  The  goal  of  a  common  data 
model  is  to  enable  and  support  interoperability  across  programs  through  the  ability  to  exchange  information  at 
system  interfaces  machine-to-machine. 


JMS  Common  Data  Model 

Common  Data  Model  refers  to  data  structures,  definitions,  attributes,  XML  schema, 
WSDLs,  etc.  which  are  common  across  JMS  and  one  or  more  of  its  components 


Goal:  Interoperable  Information  Exchange 


Plan  for  Enterprise  Data  Model  Harmonization  and  JMS  Integration 

JMS  development  has  been  divided  into  two  increments,  and  these  increments  have  in  turn  been  divided  into  a  series 
of  Service  Packs  to  facilitate  an  agile  development,  testing  and  delivery  schedule.  The  JMS  Enterprise  Data  Model 
framework  will  be  integrated  into  JMS  during  Increment  2  development  which  will  take  place  over  the  next  two 
years,  with  integration  of  all  JMS  Functional  Requirements  Document  (FRD)  capability  by  the  end  of  FY2014. 
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To  successfully  deliver  JMS  enterprise  data  framework  under  JMS  Increment  2,  the  JMS  data  engineering  team  will 
first  harmonize  existing  Increment  1  data  structures  with  JMS  Enterprise  Data  Model  vl.O.  For  efficiency  in 
achieving  data  interoperability,  the  team  will  focus  on  interfaces  of  JMS  services  and  capabilities  with  other  services 
and  system  capabilities,  developing  new  service  and  messaging  interfaces  which  are  compliant  with  the  Enterprise 
Data  Model. 

This  work  can  be  accomplished  and  integrated  in  an  iterative  manner  during  Increment  2  development  /  integration. 
Existing  data  element  structure  as  well  as  XML  schema  and  Web  Services  Definition  Language  (WSDLs)  will  be 
evaluated  and  redesigned,  as  needed  for  compliance  with  the  JMS  Data  Model.  Prototype  services  and  messages 
will  be  developed  and  tested.  Risk  can  be  lowered  by  executing  the  new  services  in  parallel  with  old  ones  for 
validation.  Non-conformant  services  can  be  deprecated  over  time 

Advantages  of  Implementing  a  Common  Data  Model 

Creating  a  common  data  model  will  require  an  investment  of  considerable  resources,  depending  on  the  size  of  the 
community  and  the  scope  of  its  mission  requirements.  However,  the  payoff  can  be  large: 

•  Data  elements  within  the  common  data  model  are  normalized,  reducing  redundancy  and  providing 
consistent  metadata  structure  to  support  reliable  decision-making  by  operators 

•  Data  structures  within  the  model  become  consistent,  reducing  or  eliminating  the  need  for  data  translators, 
supporting  distributed  data  stores,  and  enabling  more  efficient  allocation  to  virtual  machines  (VMs) 

•  Web  services  based  on  common  data  take  advantage  of  efficiencies  in  program  structure,  fostering 
improved  system  performance 

•  A  common  enterprise  data  framework  supports  data  accuracy  and  the  extension  of  system  capabilities 

Keys  to  Data  Modeling  Success 


Although  the  JMS  Enterprise  Data  Model  development  within  the  C2  SSA  community  has  been  underway  for  less 
than  a  year,  the  team  has  already  learned  a  number  of  valuable  lessons  which  we  believe  will  greatly  enhance  our 
ability  to  be  successful. 

1.  While  there  is  an  understandable  tendency  to  want  to  mandate  approaches,  it  is  important  to  engage  the 
community  in  an  open,  collaborative  approach.  Actively  solicit  and  incorporate  stakeholder  feedback. 

Help  the  community  see  what  it  will  gain  by  this  collaboration  (i.e.,  reduced  sustainment  expense  and 
improved  system  performance). 

2.  Start  with  mission  threads  and  build  use  cases  that  map  to  requirements;  develop  activity  diagrams.  Build  a 
high  quality  team  of  data  modelers  and  subject  matter  experts. 

3.  Stand  up  a  working  group  within  the  community  to  build  reference  implementations  to  show  your  data 
model  can  be  implemented  and  can  provide  efficient  capability. 

4.  Create  the  minimum  set  of  products  to  manage  interoperability  needs.  Tailor  processes  to  fit  your  resource 
constraints  and  focus  on  high  priorities.  Remember:  Perfect  is  the  enemy  of  Good.  Research  and  identify 
tools  to  help  you  manage  large  volumes  of  information. 

5.  Don’t  let  the  naysayers  get  you  down.  They  are  always  there,  but  so  are  the  folks  who  will  be  your  allies. 
Be  persistent. 
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Summary 


•  JMS  current  and  planned  component  capabilities  have  created  numerous  data  type  packages  and  XML 
schema  to  meet  baseline  data  exchange  requirements  for  programs  of  record 

-  JMS  Enterprise  Data  Model  vl.O  provides  a  framework  for  net-centric  information  exchange  to 
ensure  accuracy  &  performance 

•  The  C2  SSA  COI  provides  a  forum  for  collaboration  to  foster  interoperability  across  the  community 

-  C2  SSA  COI  provides  data  products  and  configuration  management  through  the  DoD  MDR 

•  C2  SSA  COI  team  members  (PoR  resources)  are  a  coalition  of  the  willing  who  welcome  participation  by  all 
members  of  the  community  (DoD,  Gov  agencies,  civil  and  commercial  entities,  Homeland  Security,  state 
and  local  entities,  universities,  coalition  partners) 
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